Large database systems, such as enterprise resource planning (“ERP”) systems, and customer relationship management (“CRM”) can include database objects that store and organize data, as well as database objects for accessing the data. For example, in some database systems a database object may include a table, an index, and a view, as well as a procedure for accessing one or more tables, importing data into one or more tables, or a calculation view that manipulates the data in one or more tables. One example of such a database is the High-Performance Analytic Appliance (“HANA”), which is a column-oriented, in-memory database appliance available from SAP SE, Walldorf, Germany. HANA supports both column-based and row-based storage. Pushing down data-intensive computations into the database layer minimizes data transfers between the database layer and an application layer and takes advantage of in-memory capabilities, which are becoming more common. Because the database objects of such a system include procedures and other objects for manipulating the data, an application developer may develop some of the database objects themselves. Such a process may include developing design-time artifacts that are deployed to the database as run-time objects. For example, the developer, and/or a database administrator, may at design time develop or revise one or more database artifacts that are then deployed to the database as a run-time database object. The deployment of a database artifact may result in one or more database objects and the deployment of multiple database artifacts can result in one database object. Thus, the relationship between development database artifacts and run-time database objects may be one-to-one, one-to-many, many-to-one, or many-to-many.
Each developer and database administrator may deploy one or more database artifacts in a container, which is a separate database schema and acts as a sandbox to insulate database objects from deployment and run-time errors of other containers. A container may be generated and maintained for specific application tasks and may, thus, represent actions and data elements related to a real-world or conceptual object, such as a sales order, an invoice, a schedule, etc. For example, a container may be generated for sales orders and may include instructions for performing specific tasks on the data related to sales orders, as well as instructions defining the data itself. Containers can be user-specific or group-specific. Containers may access other containers via a private synonym, if the other container enables such access. Containers may be complex, with hundreds or even thousands of database artifacts, making manual deployment of the artifacts difficult and time consuming.